REMARKS 

Claims 1, 2, 7-9, and 14 are pending in the present application. Claims 1 and 8 are in 
independent form, and have been amended hereby. Favorable reconsideration is requested. 

In the Office Action, the Examiner has rejected Claims 1, 2, 7-9, 14 as being 
unpatentable over US 6,847,613 (hereafter, Mimura) in view of US 2004/0136368 (hereafter, 
Wakayama) under 35 U.S.C. § 103(a). 

The Applicant now amends independent Claims 1 and 8 as seen below and in the 
attached claim amendments, in order to (a) clarify that all of "packet type," "pattern extraction 
position," and "retrieval pattern" arc selected in accordance with a user policy, and (b) to 
distinguish between "the retrieval pattern" set in the table according to the user policy and "the 
(retrieval) pattern" extracted from the received packets: 

1 . A statistic information extraction method comprising: 

a first step of setting in a table a packet type, a pattern extraction 
position within a header of a received packet corresponding to the packet type, and 
a retrieval pattern corresponding to the pattern extraction position, the packet 
type, the pattern extraction position and the retrieval pattern being selected 
in accordance with a user policy; 

a second step of extracting a pattern from received packets, based on 
the pattern extraction position set in the table when the received packet 
corresponds to the packet type set in the table; and 

a third step of storing statistic information of the pattern extracted 
from the received packets, when the pattern extracted from the received 
packets matches the retrieval pattern set in the table. 

8. A statistic information extraction device comprising: 

a first means setting in a table a packet type, a pattern extraction 
position within a header of a received packet corresponding to the packet type, and 
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a retrieval pattern corresponding to the pattern extraction position, the packet 
type, the pattern extraction position and the retrieval pattern being selected 
in accordance with a user policy; 

a second means extracting a pattern from received packets, based on 
the pattern extraction position set in the table when the received packet 
corresponds to the packet type set in the table; and 

a third means storing statistic information of the pattern extracted 
from the received packets, when the pattern extracted from the received 
packets matches the retrieval pattern set in the table, (emphasis added) 

The above claim amendments also include the correction of the word "meets" to — 

matches- as advised by the Examiner. 

The Examiner has argued on page 4 of the Office Action, as follows: 

"a retrieval pattern which are selectable in accordance with a user policy (Fig. 7, 
flow identifier 75 that corresponding to a retrieval pattern and includes SIP (Source 
IP address), DIP (Destination IP address), PT (Protocol Type), and ST (Service 
Type, i.e. packet type), etc, that characterize the flow that may be monitored for 
statistics gathering); column 5, line 65 through column 6, line 12 disclose these 
details; column 1, lines 18-28 disclose a user defined policy (i.e. best effort 
transmission performance using the maximum available resources for 
communication in the network))" 

However, it is respectfully submitted that "best effort" disclosed by Mimura is based on a 
network provider's policy (column 1, lines 18-28) and not a user policy, as recited in Claims 1 
and 8, which is a policy desired by the user. Moreover, with respect to Mimura's flow identifier 
75 that the Examiner has equated with the claimed "retrieval pattern" as above, SIP, DIP, PT and 
ST are not selectable according to such a "best effort" policy. 

Therefore, Mimura fails to teach or suggest the feature "a retrieval pattern corresponding 
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to the pattern extraction position, the packet type, the pattern extraction position and the retrieval 
pattern being selected in accordance with a user policy," as recited in the above amended Claims 
1 and 8. 

The Examiner has also argued on page 4 of the Office Action as follows: 

"a second step of extracting a retrieval pattern from received packets when the 
received packet corresponds to the packet type set in the table (column 2, lines 21- 
27 which disclose that when an IP packet arrives at the meter 20, the meter checks 
to see whether the IP packet matches any of the pre-registered communication flow 
conditions, such as the match between the source and destination IP addresses 
specified in the packet header and those pre-registered as the conditions of the 
communication flow; column 6 line 59 through column 7 line 29 describe the types 
of statistical data gathered)" 

However, it is respectfully submitted that "extracting a retrieval pattern" is nowhere 
taught or suggested in Mimura in the portions referenced to by the Examiner. Moreover, the 
Examiner has remained silent on the feature of "based on the pattern extraction position set in 

the table" in Claims 1 and 8. 

Therefore, Mimura fails to teach or suggest the feature of a second step of Claim 1 or a 
second means of Claim 8 "extracting a pattern from received packets, based on the pattern 
extraction position set in the table when the received packet corresponds to the packet type set in 
the table." 

The Examiner has also argued on pages 4 and 5 of the Office Action as follows: 

"a third step of storing statistic information of the extracted retrieval pattern when 
the extracted retrieval pattern meets matches the retrieval pattern set in the table 
(Fig. 7 shows saved statistics data 72 being forwarded as a packet from a previous 
monitoring switch to a next monitoring switch); Fig. 8 shows similar details; column 
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4, lines 51-67 and column 11, line 29 through column 12, line 62 further disclose the 
details of the stored statistic information of the extracted retrieval pattern)" 

However, it is respectfully submitted that considering that Mimura fails to teach or 
suggest "a retrieval pattern" and "extracting a retrieval pattern" as described above, the feature of 
third step and third means of amended Claims 1 and 8, "storing statistic information of the 
pattern extracted from the received packets, when the pattern extracted from the received packets 
matches the retrieval pattern set in the table" "extracting a retrieval pattern," is also nowhere 
taught or suggested in Mimura cited for this feature by the Examiner . 

The Examiner has further argued on page 5 of the Office Action as follows: 

"However, Mimura et al. do not explicitly disclose a pattern extraction position 
within a header of a received packet corresponding to the packet type. Although, 
when the fields corresponding to the retrieval pattern occupy fixed positions in the 
packet header, the position of the retrieval pattern is implied and not explicitly 
required, as is the case with Ethernet header." 

However, the feature of "the pattern extraction position being selected in accordance 
with a user policy" enables the method of Claim 1 and the device of Claim 8 to deal with the 
changes of the user policy. Therefore, this feature should be explicitly required despite the 
above argument by the Examiner. 

Finally, the Examiner has concluded on page 6 of the Office Action as follows: 

"Therefore, it would have been obvious to a person skilled in the art at the time the 
invention was made to use pattern extraction positions within a header of a received 
packet corresponding to the packet type, as taught by Wakayama et al, in the 
method of Mimura et al., so as to easily locate the position, within the IP header, of 
the fields that need to be extracted and analyzed." 
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As seen in amended Claims 1 and 8 above, all of "a packet type," "a pattern extraction 
position," and "a retrieval pattern" are selected in accordance with a user policy and are set in 
a table by the first step of Claim 1 and the first means of Claim 8. 

However, it is respectfully submitted that according to Mimura on column 6, lines 1-3, 
conditions for identifying communication flows are assumed to have been registered beforehand 
in the flow table 4, and therefore cannot be selected in accordance with a user policy . 
Accordingly, Claims 1 and 8 of the present invention cannot be achieved by combining Mimura 
and Wakayama. 

Also, it should be noted that the object of the present invention is to provide a statistic 
information extraction method and device which can accommodate to a case where a kind of 
statistic information is extracted by a user policy is changed and a case where a kind of 
statistic information cannot be preliminarily specified (See, e.g., page 4 lines 9-13 of the 
specification of the present application). However, neither Mimura nor Wakayama teaches or 
suggests the need for dealing with the changes of the user policy or the statistic information that 
can not be preliminarily specified. Therefore, it is respectfully submitted that there is no 
obviousness in combining Mimura and Wakayama in order to achieve the above-mentioned 
object of the present invention as motivation. 

Accordingly, it is respectfully submitted that amended independent Claims 1 and 8, and 
the claims depending therefrom, are patentably distinct over Mimura and Wakayama, alone or in 
any possible combination. 
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In view of the amendments and remarks set forth above, this application is believed to be 
in condition for allowance which action is respectfully requested. However, if for any reason the 
Examiner should consider this application not to be in condition for allowance, the Examiner is 
respectfully requested to telephone the undersigned attorney at the number listed below prior to 
issuing a further Action. 

Any fee due with this paper may be charged to Deposit Account No. 50-1290. 

Favorable reconsideration is earnestly solicited. 
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